There is little that is realistic about suspension and engine damage in LFS and I don't see any benefit in trying to make the repair times realistic. Obviously not now, and probably never.

But that could be some whole philosophical debate. In my opinion the damage should be sufficient to stop you doing bad things in races that you wouldn't do in reality - that keeps the racing real, which is the point here - but it's actually "better than reality" that you can get these things fixed super fast and not be entirely knocked out of a long race for some minor error like an early downshift.

I mean, this whole philosophical debate about realism can go pretty deep, and I remember someone suggested having a job in the game to earn money to buy your car parts. Well my opinion is, if you want it that realistic, just use the real world, get a real job and go real racing. Then you can find out how much broken parts cost. To me, a game can be, in some ways, *better* than reality. Taking LFS as an example, you spend a lot more time racing and a lot less time fixing things.

At the moment, for this version, in which engine damage has finally become repairable, I don't yet see any inconsistency between the super-fast engine repair times and the super-fast suspension repair times.

About an option to use or not use the name coloured arrows on servers without lap timing:

Quote from Ibtasim6781 :

An option for users to click on. The reason mainly apart from aesthetics/gameplay-wise is that its not very useful outside those specific events (Football, Derby, etc etc) so it looks more of an option to use when in those events. At least thats how I see it

I wonder where it will be seen, other than football? Which servers don't use lap timing?

Cruise servers is one example (though I'm struggling to think of others). Degats pointed out a possible issue, but we haven't heard from anyone if they actually found it a problem or a benefit in reality.

Quote from Degats :

Not sure how good it would be for chases on cruise servers, as it will make it even easier for police to follow where a car is going on the map. Given the highly competitive nature, it would change the balance a bit.

Would be interesting to hear if people like it in cruise servers.

Quote from superlame :

Maybe a good idea is to have the colorful arrow as an option inside Misc?
For the people that think it is too colorful for them, they can switch it back to the default (Pre 0.7D3)
Options - Misc - Enable colorful arrow map?

As you say: Maybe. I hope to hear from people what they actually feel about it.

At the moment we are just talking about solutions to theoretical problems that may exist.

I see two problems with acting too fast:

1) We have not received any feedback at all about what people think about it on servers (if they actually like it or not).
2) The question of server option vs user option. Both seem as valid as each other but it's probably not a good idea to implement both, as they can conflict. Before anyone tells me, yes I know we could have server option "ON / OFF / FREE CHOICE" to avoid actual conflict between two options (or server option "ALLOW COLOURFUL ARROWS IF USER WANTS") but interaction between server option and user options is more complicated than I really want for this simple fun feature.

My job is not to dictate the answer but to assess feedback from people who are actually using it, compare this with suggestions and see what comes up.

Obviously as mentioned I like the easy solution of "no option" (as now) but still need to hear feedback from people using it. Maybe less useful at this point is thinking of options for other people whose opinions we have not yet heard and may or may not like it.

Thanks for the feedback about engine damage. It looks like most people would like it displayed (as a number).

About the repairs, and options for servers to allow it, or for users to select whether it should be done or not in pits, InSim output etc. that is massively beyond the scope of this patch. I've got far too much work to do and can't get into things that take many hours to do, even if they are good thoughts you are having.

My suggestion was that, maybe, (and I haven't even checked the code yet) a small amount of damage could result in the already existing "minor damage" time delay and a larger amount of damage could result in the already existing "major damage" time delay.

There's already a damage repair option and that would apply to engine and suspension all with the same option.

That's all I can offer at this time, no interface, no options, just an opportunity for engine damage to be fixed by the super fast mechanics while the other super fast mechanics might be working on the suspension and doing a incredible job fixing the bodywork without a trace.

After a longer gap than usual there are a few things to report.

Soon after the last report, after fixing a few things that were sitting on lists, I added a new type of object that can be used in the track editor to connect up other objects more easily. Instead of the usual cross-sections connected by segments (with curves) this new system allows the simple addition of triangles. As if in the modeller, but between different cross-sections. It's hard to explain but it does simplify tasks by making it a lot easier to fill odd-shaped holes!

After my day of fixes on Fern Bay, Eric decided to have a quick go at it, really just fixes for the new lighting system. There were still some holes to fill, which are important for shadows, and he wanted to add some shine (specular effect) to the roads. He updated a few textures here and there in addition to the road surfaces but did the bare minimum of modelling. As stated before, there isn't time to bring Fern Bay up to the modern standard before the coming release, but it was certainly worth a few days tidying up.

After Eric sent me the update, I noticed a few remaining issues that I could improve with the use of new editor functions that I quickly coded. It is useful for me to spend a little time in the track editor because I often think of a few new functions or improvements to do.

Trying to get things finished can be a lengthy process! After the Fern Bay update we ended up taking on an extra task, almost by mistake. Eric wanted to update some of the layout objects which looked quite tired and old. His plan was just a few days brushing up a few objects. Quickly the task expanded and we started to make use of the new mapping configuration and monochrome colours system, that help maintain variety in the track editor, now extended to the layout objects. With a single object selected there can be several variations on the texture cutouts that are displayed. There was community involvement and we took on some of the ideas. There are definite benefits, so it was worth a week on the job. Even if that week turned out to be two weeks! We're near the end of layout updates for now!
Public thread about layout objects: https://www.lfs.net/forum/thread/101752

Eric and I have discussed the need to try to get to the release and only do what is necessary from now on. We want to do a lot of things but they can be done after the release.

On my side I have another day or two on layout functions, and there are some editor features to look at that could help Eric complete South City. Sometimes when buildings follow the edges of existing roads they can end up quite complex and bring up issues that can be made easier by certain new editor functions. I enjoy doing editor functions but of course, I am trying to get off graphics to finish the tyre physics and get to that public beta as quickly as possible.


Log of updates:

Layout marshals also needed to pick up lighting from lightmap (objects already do)
- marshals are done a different way and do a single lightmap reading when first drawn

Improved track editor function for setting height of multiple points
- also generally updated initialisation of text entry to the new style in a few places

Added a new type of surface that can be added in the track editor
- an extension of "section end triangles" but now can connect to other cross-sections
- as arbitrary triangles between track objects they can make it easier to fill holes
- turned out this is was a bit more work than expected in the track editor
- when objects can refer to others a lot of care must be taken with delete functions

Fix: track editor bug - surface properties were not updated correctly when changed
Fix: a physics surface debug display was not using the thread-safe copy of wheels
Fix: suspension diagram was also not yet updated to use thread-safe variables
Fix: time could move on up to 30 sec in track editor then car would catch up on exit

Eric sent a minor update of Fern Bay with specular lighting added to road textures
- other small updates as well including filling all the holes as seen from above
- although it's not a full update these are important fixes for the shadow system
- also improved a few textures around that needed brightening up in addition to shine
- the general effect is improved as you can see in the attached screenshots

I spotted a few remaining Fern Bay issues and went into the track editor to fix them
- changed/added editor functions that helped with searching/updating multiple objects
- a benefit of me spending time in editor is I sometimes come up with useful functions

Eric started to do a quick update on the layout objects that would take a few days
- it is not really the highest priority but seemed like a quick improvement at first
- job got a little bigger as we added support for selectable "mapping configurations"
- these, along with a colour selector, allow more variety without more object slots
- so we can have e.g. more signs or cone colours using the new improved objects

Discussion with Eric about the new world triangles hole filling system
- it can help fill holes in South City, either large holes out of town or small holes
- Eric showed me some of the challenging things at South City to finish in a good way
- looking at the real situations that come up, we thought of some helpful improvements

Worked on the updated (and new) layout objects
- asked community members if they had suggestions for a few useful objects
- some useful things came from that thread: https://www.lfs.net/forum/thread/101752
- using the new mapping configurations and monochrome colours, more variety is possible
- with a single object selected, multiple configurations can be chosen (e.g. letters)
- in the screenshot you can see most of the new objects but not showing all variations

Remember that if you do the things we recommend, your mod can be processed super fast.

Example 1:
Mod creator creates a development thread, shows progress, lists sources and shares info with public during development. Finally mod is done, submit. SUPER QUICK PUBLISHING

Example 2:
Mod suddenly appears submitted, EITHER claims original work but looks like it comes from another game OR mod is from sketchfab (etc) claimed as original work by sketchfab uploader, but looks like from another game. Reviewers have no way to know if dodgy looking mod is really legit, strong suspicion that it's not. Unwilling to publish. VERY SLOW PUBLISHING

These are just two examples. Other mods may have reasons for super fast publishing and many other mods may also look dodgy for whatever reasons, like FAKE "work in progress" images, that are hard to prove one way or another.

I'm not going to get in a discussion here. In fact I will not subscribe to the thread. But it's amazing how many people IGNORE our advice for how to get mods published quickly, then complain that it takes a long time.

The reviewers are doing their best. Please help them, by doing the proper thing with mod development threads, provide genuine proof of your investigations into the legitimacy of any sources. It is not the job of the reviewers to do that. It is your job to show beyond any doubt that the mod is legitimate.

Would the kerb objects like you see at Blackwood do the job?

Six more days have elapsed and there is a little more progress to report. It's interesting that most of the work was really nothing to do with multithreading. I had to remove a system that used to clear out disused skins from RAM, because the way it worked was not thread-safe. As mentioned before, we needed a new system that works with all car textures (not just skins). So I've implemented that as described below. You can see it doing its thing in the attached screenshot.

Another milestone is that I sent a version to Eric with a cautious recommendation that he could try using it for development. It has been stable apart from one thread-related crash - an FF device was being uninitialised at the same time as it was being used on another thread.

One of the next steps is a pit-out glitch reduction system that is a lot better than the old one. To reduce a glitch when a remote player leaves the pits in the current version of LFS, while you are driving, no textures are loaded from HDD (or SSD, obviously ). The car model is built but may appear white where there should be textures, if those textures were not already loaded for some other car. It has often been reported as a "white cars" bug although it's really not a bug at all, and their cars are rebuilt with textures when you stop at some point.

In the new system (as reported on Sat 29 Oct) a remote player's car model is not built as soon as they leave the pits, but only when they are within your view. But currently all their textures will be loaded immediately as I had to remove the white cars pit-out glitch reduction system.

My new plan is to make it that a car may appear white for a short time, but one by one over the coming frames, the textures will be loaded. The entire model will not have to be rebuilt at any later point, only the actual textures will be loaded, without the car's model even noticing that. This will also cover a similar situation when a remote player joins and their skin is downloaded. That skin will be applied to their car without needing a full rebuild. I expect this to take a few days. The principle is that when a texture is requested, if it is not already in RAM, all information that is required to load it is stored in a "Texture" object that doesn't have its own D3D texture (instead pointing to a small plain system texture, probably grey). The real D3D texture will be loaded at some point (up to a few a few seconds later) and replaced in the Texture object.

Now that multithreading is basically done, I'll stop reporting daily progress and go back to a more normal style. I hope to report more regularly than in the past, as I know the reports are interesting for some people and the use of a closed thread has allowed me to make unofficial reports without them becoming a distraction.

I hope the detailed daily calendar has been of some interest, and some insight into the general complication of the work done by a game programmer. We don't just do some super-slow magic, conjuring up cars and tracks. Instead, it's mostly a lot of strange and abstract stuff that you might not think of immediately. It has been interesting for me, looking back and seeing all this stuff and helps me to understand why my time estimates are always so far off.

Anyway, here's the last of the daily detail calendars, for now:

31 Oct (evening)
FIX: Escape from MPR click to point in replay continued visibly speeding after Esc
FIX: Exposure was not reset after exiting from game which could cause overexposure

1 Nov
FIX: Lights were not switched on when starting a night replay after daylight replay
Removed function "check_for_skin_space" which was accessing Race at the wrong time
- this function ran through texture and car lists to remove older skins from memory
- it is not thread-safe as it was accessing Race (game code) during graphical render
- a better way to identify unused textures (not only skins) is now needed due to mods
Gathered remaining things to do onto new sheets of papers to make them more readable
FIX: Crash when loading very old cars, then a memory leak when loading very old cars
Sent update to Eric with suggestion that it may now be safe to use for development

2 Nov
As mentioned we need a system to remove textures and skins from cars no longer in use
Started coding a method to detect which already loaded textures can be deleted from RAM
First step: to know exactly which textures are used by cars (and helmets) but not world
- imperative not to delete any textures that are still in use or there will be a crash
- change all texture and material initialisation functions to specify usage (car/world)
- this also applies to "re-use" functions, in case a car texture is later used by world
Eric reported a crash bug with ALT+TAB from full screen and provided the crash address
- crash address was in LFS code, setting a Force (on a FFDevice that still existed)
- thread-related: controllers were being shut down while game code applied a force

3 Nov
Examined yesterday's code and brushed up a bit, ready to start with the second step
The algorithm must identify all car textures that are not in use and can be deleted
- avoids an excessive build-up of textures in RAM as cars come and go over time
- run through all textures marked CAR and IN USE - set to DISUSED (and add time stamp)
- new 3D object and car functions to run through all textures and mark then as IN USE
- call car functions on every car in the race, game setup screen, garage (and helmet)
- whatever remains as DISUSED is no longer used by an existing car so can be deleted
Now the focus is on when to run the described algorithm and which textures to delete
- we don't want to delete textures every time it's possible as they may be needed soon
- for example a player who goes to the pits is likely to exit again with the same car
- another example: whole game exits to game setup screen - no point removing textures
- the "last used" time stamp could help to delete textures not in use for a while
Wrote a system to remove materials and textures after some time
- if any car is added or removed in game, a short countdown is started
- after 3 seconds, disused materials and textures are identified (algorithm above)
- then 1 disused material or 1 disused texture is deleted every graphical frame
- but only materials and textures set to unused at least 5 minutes ago are deleted

4 Nov (morning)
Yesterday's algorithm does the job and unused textures always get removed eventually
- avoids build-up in RAM but will sometimes remove textures that will be needed again
- algorithm can be adjusted later but now it's best to work on delayed texture loading
- cleaned up some code and added debug check for texture delete while material exists

Quote from felplacerad :

Not LFS, exactly, but Scawen and Eric was mentioned (and praised!) in this documentary about Black & White! 👍

Why has Black & White Been Abandoned? - Noclip Greatest Hits
https://m.youtube.com/watch?v=GtNvEna6bxc

Direct link to the segment:
https://m.youtube.com/watch?v=GtNvEna6bxc&t=348s

Thanks for the link! I watched it with the family yesterday evening. Interesting to see how Peter has changed. Well, I remember I was in my late 20s when we all went to his 40th birthday party, and now I'm 50, so he must be in his 60s now.

Nice that Eric and I were kindly mentioned.

Quote from felplacerad :

Quite a funny story of how Scawen got the job! @Scawen, is it true? 😂

That story about how we met isn't quite true though it's based on facts. That's kind of what Peter does.

In fact I did work as a motorbike courier for a company called Black & White that was based in Twickenham. But I was looking for a job as a programmer (I had previously worked at a company called Digital Integration, on the Hind helicopter simulator) so I contacted a recruitment agency that specialised in game jobs. Quite quickly they came up with this interview, with someone who I would surely admire (Peter Molyneux). Actually I hadn't even heard of him before but went for the interview as it sounded good. I rode down on my bike and had a good meeting there, in which we of course talked about my job at Black & White, which was funny as the interview was about working on the game called Black & White.

I had a nice demo (with an animated car and some people and dogs that could walk around on a lumpy landscape - actually it's the same program that evolved into LFS) so they were able to offer me the job on the spot. I said, thanks and I'll consider it. But he looked a bit shocked and said, why aren't you accepting the job now? I said, well I thought that it was the right thing to do... and actually I decided to just accept it then anyway. That was the right move as it was a very good job in the end although there were ups and downs.

Quote from mbutcher :

That's brilliant. I want to play it now

We got it running a few years ago, using a boxed game and the fan patches you can find online. Leo and Nicole enjoyed it quite a bit.

Quote from nacim :

Funny how if you look closely at the game editor at 6:00, it look really close to the original theme of LFS UI

Quote from felplacerad :

Woah, I didn't realize that at first. But yeah, it most certainly does!

...

I'm sure you can find menus in LFS that resembles B&W even more closely. Autocross editor, perhaps?

How about this attached picture from the video, you can see a creature editor I built in game, using my own buttons system that I had imported into Black and White.

Compare that with the attached image of the vehicle editor.

The early LFS in-game menu style was more inspired by Quake 3 Arena.

Well... seeing as you are interested... it might be helpful for people to understand the thinking behind the patch, some info about how things actually go in the real world as opposed to some imagined perfect world where I can continue coding full time without any issue. And what the plans are as I see them.

Since version B was released, first I did some finishing work that week and put a little time into a special version that can really help with events such as the football (Soccar) event. As the ball can run on the host, it works so much better. It's a special server version that could be used for some special cases in future. Something I really wanted to do, even since before the first public version of mods. It's an interesting concept. The reason I even *do* this job, is so that I can follow interesting concepts and get them done!

Then I got Covid, and it was the kids half term. So not much done that week.

As you know, we have a public review system now, and it has been fairly common for people to submit mods from other games, usually by mistake (e.g. they got it from a supposedly legitimate website but the person who uploaded it there didn't actually make it). We can't host such mods, so it's important to have the wireframe view that helps people to examine the model and see if it has come from an illegitimate source.

I don't like the fact that there was a crash in the version. Even if rare... there's one reason that LFS doesn't crash much. It's not because it's 'old' or 'can run on a toaster' etc. It's because I always try to fix every crash, and respond when community members report one.

A couple of other bugs and issues were spotted in the football event so I did a quick fix for them. The shadow bug and the wall riding. Good to fix them. Then when fixed, why hold them back? You guys can have the fix too!

One important thing, for people with worse internet connections, is the ability to download mods while joining a host, instead of after you have joined. It was on my sheet for months, long before the first public test patch of the mods system was ever released. I actually did that in a day yesterday. It has been a little hard to get right back to work after Covid.

Although my Covid was classed as 'mild' I can tell you that for me it was a lot worse than a normal cold. I had some rough nights, weird aching muscles and all sorts of symptoms, separately and sequentially. For info I'm 50 years old and semi-fit meaning I run and ride bikes a bit and walk a few km nearly every day if I don't run or ride. I eat a healthy diet, do not smoke (for 10 years) and rarely drink (and if I do, it's one glass). I actually thought Covid would hit me less hard. As I work from home, I was not vaccinated. I got the Covid from Leo who brought it back from school. I'm not asking for sympathy, it was my choice. I have my reasons.

So the download mods thing was a real good day of work yesterday. I had been somewhat distracted by the war and programming seemed very confusing. It's hard to explain to a non-programmer, quite how hard programming can be and how organised you have to be and have a good short term memory and sometimes keep notes as you go. Even in this case, when I wasn't really doing something entirely new and inspirational, there's data collection, packet sending, list processing, and it's quite simply a lot more involved than you might imagine!

I want to call a stop to working on mods, as you know, with a solid version out there. So that's what this test patch is all about. A simple update that allows me to get on with the tyre physics. There are a lot more things I could do with mods but I want to stop, because when we get the new physics and graphics out, it'll be easier to work on things as I won't have to merge two separate versions.

Thanks for the discussions and historical context.

We, the people, need to make sure we remain friends, because our 'leaders' are doing a terrible job!

We have so many terrible environmental crises ongoing and need to adjust our ways of life and the things we aim for, but in so many countries we install the very worst kind of people as our 'leaders' - people whose main interest is money and power.

Putin, Bush, Blair, Johnson, Bolsonaro, Morrison, Erdogan, Trump. What a bunch of standout fools. All they can do is take a situation and make it worse. The EU leadership isn't much better, their environmental care is a joke and is far down the list compared with money making.

Hello Racers,

It is nearly two months since the release of the new mods system which has been very popular and well supported by the community. We have made a lot of improvements in LFS since then and you can now get them in a new patch, 0.7B.

The mods screen looks better and works more efficiently. You can now set favourites and rate mods from in game. The ratings help mods become approved when they are well received by the community.

There is a new skin viewer mode in the garage which is useful when you are working on the paint job of an LFS car or a mod. You can also export a plain skin template or a wireframe from the garage as a starting point for a skin.

Support for electric vehicles has improved, including regenerative braking. AI paths can now be generated for mods and there are various fixes and improvements.

Community members have been creating a lot of mods. Our reviewers have found it hard to keep up as so many have been submitted. It is important for us to check the source of models to make sure that copyright is respected. Reviewers have also been checking some of the best mods and giving them an 'approved' status which allows them to be displayed more prominently. To help the reviewers we have now implemented a 'public review' system in which new mods will appear on the forum to be checked by S3 licensed community members before they are first published.

See the full list of changes and how to install the update on the Live for Speed version 0.7B page.

- LFS Developers

Hi, yes that skin problem is totally in the model. In fact the user shouldn't be supplying a skin at all, when they have not even started to do a proper job with the skin mappings. Please report it on the model's thread if you find such an issue.

About the tyre temperatures, I'm pretty sure there is nothing wrong with the tyre order in the output telemetry. Please can you make a bug report with the developers of the software that reads the data? I assume it is OutSim rather than OutGauge. The wheel data is output in this order:

Rear left
Rear right
Front left
Front right

Ah, sorry. You are right, that command doesn't work for mod Skin ID. The fix was that it needed capitals for the official car 3-letter Skin ID.

There is no similar command for mods. I think I could make one that works on the full name. I can't make one that works on mod skin ID.

Then there could be a command like:
/mod formula xr-e

Would that be helpful? I guess it could do the job, although I don't think I have ever used the /car command.

Or, now that I think of it, I think the /car command could be re-used for mods. As mod names must be at least 4 characters, it could accept:

- official car Skin ID (e.g. xrt)
- official car name (e.g. uf 1000)
- mod vehicle name (e.g. formula xr-e)

But not mod Skin ID as that is not known until the vehicle is loaded.

Last edited by Scawen, Sat 5 Feb 2022, 13:39.

I think what Draggo is saying (but I haven't looked in the mod) is that in this case you could use the mapping of the central big stripe, for all the side triangles. I guess that should do the best job, which should actually look quite reasonable in the case when people aren't using different colours. And it would even put black squares over the windows.

Of course it would be 'wrong' when people have used different C2 colours in their colour config.

In reality the LOD distances have been set for car-sized objects and I haven't given thought to adjusting them for bus-sized objects. It could be that it would be a good idea to use LOD2 up to a greater distance before switching to LOD3.

EDIT: Or maybe the C2 side mapping would be a better choice for the LOD2 side triangles than the C1 side mapping?

I forgot to mention that it is quite a good idea for mod creators to switch to a low User LOD setting when testing their mod, to see how the LOD popping looks, in that exaggerated state.

Last edited by Scawen, Wed 26 Jan 2022, 20:40.

Hello mod users,

I will need to fix this issue, where certain setups of certain mods, then driven in a certain way, can cause a physics glitch that results in a sound problem that affects all users who are within range of that vehicle. There may be a bad sound then a total loss of engine sounds.

So does anyone know of a simple way to reproduce this? If necessary, I could trawl through an MPR from a cruise server but my job would be a lot simpler if this can be reproduced on demand, or in an MPR with just the one vehicle in it. It's a lot easier to track down something in the debugger if there is less going on.

Thanks!

EDIT: I did fix this in the past for some vehicles. It was something to do with the golf cart. As it had small wheels their rotation could go wrong on remote computers with some gear ratios or final drive ratios. It was not intended by the user driving the car and it came with a graphical glitch too.

Last edited by Scawen, Mon 10 Jan 2022, 09:00.

I know the effect of manipulation to pass targets, it is a terrible social problem. Here in the UK, targets set by governments produce highly questionable results in huge institutions, such as social health care and education.

But here in our tiny corner of the world, our algorithm for approving mods is by no means settled. At the moment I am simply trying to encourage people to do the right thing and actually give ratings to mods they like. I find it a bit disappointing that a mod can have over 4000 downloads, yet not even 20 people bothered to give it a rating.

Other people seem to just want the developers to spend their entire life examining mods, rating them in detail, checking them against a long checklist and passing those that pass on all counts. It seems there are more people saying we should do a better job examining mods, than there are people actually rating mods! Well... that's not going to happen. Developers have to develop and our volunteer reviewers aren't going to spend all their free time looking at mods, so there will have to be more community involvement if we will have a workable system in the end.

But I never just blame everyone else. If people are too lazy to give ratings, I say "what am I doing wrong" and have to divert my attention away from developing other things and start looking into how to solve this. Either think of an entirely new system (again) or perhaps improve this one. I was wondering today if it might help to put rating stars in the garage screen. To save people having to click the button that takes them directly to a mod's web page. But is it that extra click they don't like, or is it the mental effort of having to choose a few numbers between 1 and 5?

Last edited by Scawen, Sun 2 Jan 2022, 13:58.

Quote from andmie17 :

The question is: Is the "3 player scenario with one license" being removed with 0.7? Do we have to purchase further licenses to be able to run multiplayer sessions with S3 content?

Yes, in fact the license used to allow two players on a LAN with one license but that is no longer possible with 0.7A.

Our business was being killed by piracy (there was no longer enough income to live on) so we had to either get another job or take a different approach - add new functionality or content and not release any server code at all.

But the old version is still available if you want to use it.

Quote from zamzing :

10 dollars 18 pounds shouldn't be a big difference for you rich countries

See this is the thing, apparently nothing should make a difference for us rich people.

True situation: sales went down and down for the last few years (partly because of piracy, partly because we didn't release enough new stuff). In the end (and I'm not asking for sympathy) the income wasn't enough to live on, we need food and have to buy clothes for the two children to go to school, must pay some bills. Forget about holidays and luxuries - luckily we live in a nice part of England and can go for a countryside walk for most of our entertainment and sanity. Yeah, we're lucky. Now I'm not about to say we hit a dire situation, actually we have some savings to go through a hard time. BUT the income we were receiving was not enough to live on sustainably. Britain is a rich country, but that doesn't mean we are all rich! If we don't earn money, we'll have to get another job, and can't develop LFS any more!

I'm not asking for sympathy, we did some hard work and released this mods system, and income is up right now. How long will it last? I don't know! I hope it will stay at a sustainable level. But there isn't anything so sure as to say we have a guaranteed income so can reduce the price any amount because we're just gonna be so nice. No, we have to work for a living and try to maintain this product so we can live on the income. And each customer is a cost because we have to continue to provide a service to them for many years to come, as we have done for approaching 20 years now. It costs money and time, which is why we ask for a reasonable one-off payment.

Quote from raidho36 :

It struck me as odd decision to prevent your own hosting. Then I remembered that you're an indie company so you need all the money you can get, so I figured being extra tight on piracy is fine.

Umm... well it's more like, we need some money to pay bills, otherwise we'll have to stop development and take up another job. Get it?

And if I am to take you seriously and disregard my suspicion that you are just a troll... yes our business model does depend on one-off payments and is ridiculously cheap for a lifetime subscription, so most people would think of that as unsustainable. But when we've thought about it, we realise that there are always new people coming along, as there have been for some time, approaching 20 years now. And those who do pay once and use the game for years and years, are actually supporting the game just by being here and part of the community. We don't really need more money from them.

The only real problem is piracy, which stops people needing to buy the game (instead they give money to a pirate and install fraud software - but that's another story). So we decided to to the hosting ourselves, which we allow people to use free of charge, or rent very cheap permanent servers.

But I perceive you will believe what you want to believe.

What I would like is to do all the 100 necessary things that take 10 minutes to do, in 10 minutes total. That would be great.

Ah.. forgot to mention. The team that will lead this response. Guess who that team is... its YOU!

In case you were wondering, we have a very tiny income to live on. This is not a big company that can hire a team of technical support to answer questions. We rely on the community members helping each other. They do a really great job of that. I think you have the wrong idea.

EDIT: The information here is no longer correct as we have a new system for mod approval: https://www.lfs.net/forum/thread/95940


Hello Modders,

We are really impressed by a lot of the mods you have been working on, and are very happy to see so many people learning to use our development tools during this testing period.

So far we have been unable to keep up with the number of mods and updates submitted, so we have decided to impose some time limits. These may well be a temporary measure while we try to figure out other ways to keep the quality high and the update frequency down a bit.

The general idea is to prepare your mod well, test and improve it a lot in single player, hopefully discuss it in the Mods Work in Progress section, then when it's pretty good, submit the first version. That's what we mean by "Work in Progress".

For us, "Work in Progress" doesn't mean you've just started working on it. Obviously work is in progress at that point, but for a submitted mod, it means it's in a good state, really fun to drive, everything works and it is in the final stages of development.

Good mod creators will really take their time to work on a mod. It's not a 10 minute job like in my test video with the UF 1300. More like weeks of work, though this depends on the type of mod you are creating and what source materials you have. The reviewers are far more likely to take an interest in proper mods that add something to Live for Speed. They aren't very inspired by LFS cars with slightly different engine or tyres.

So the new limits are:

Quote :

You can request a first-time mod review only once every 7 days
You can request a review for an updated mod archive once every 48 hours
These time limits are set and measured after each review approval

You can have one pending mod review at any moment

To express that a different way:

Quote :

If you have no mod awaiting approval at all, then:
- You can request a first version mod review if 7 days have elapsed since your last first version mod was approved
- You can request an update review on a mod if 48 hours have elapsed since that mod's last update was approved

We hope this will not cause inconvenience, but instead encourage people to take their time to get things right before submitting new mods or updates.

Thank you!

Last edited by Scawen, Mon 22 Nov 2021, 11:31.

Quote from pajkul :

I'd just love if you could stop working on these relatively small things that distract the main development and focus on that instead.

Part of my job is to understand what is important and work on it. You haven't been following this thread or the test patch properly, or you wouldn't say that.

If I take 1 minute out of my several years of development, to enable road tyres on formula cars, it probably isn't going to be a really big deal. But to start enabling rallycross hotlap tables for formula cars would be kind of stupid. It's not up for discussion at all. Anyone else is welcome to create their own hotlap tables for formula cars doing rallycross on road tyres if they want to. Maybe it'll catch on, who knows? But LFS developers aren't going to do that.

If you actually look what has been going on, you would see that I've been working on a lot of important things to improve the online racing experience, that happens every day, right now. It's a few weeks of work, to make important improvements for everyone to use while they wait for the other graphical and physical updates. The drift lock and new tyre allowances are a couple of minutes each. Very little to do with what I have actually been working on.

What some people don't seem to realise is all these changes also go into the new development version. I spend almost no time at all working on things that don't improve all future versions of LFS.

Quote from nexttime :

So it's not 12pps at all times?

No, that would cause an enormous increase in server bandwidth and intolerable CPU usage from the extrapolation (prediction) of the position of remote cars. In the case where the remote player has a high ping, the CPU usage can become quite bad because, every time a packet is received, LFS must run the full physics from when the packet was sent, up to the current time. That could be 100ms, so 10 full physics updates and if that was 12 times per second that would be 120 physics updates per second and this would exceed even the normal physics calculations.

I ask people to consider turn one situations when a lot of cars are close together and there is a lot of physics usage and the cars are drawn at high resolution and the frame rate drops. I am fully aware of this problem and I am always trying to avoid it.

Along with this huge cost, there would also be only tiny benefits, from sending more packets when the previous packet already provides a good prediction.

There's no point in using a sledgehammer to crack a nut.

This is why the code tries to send new position packets when the previous packet can no longer be considered to provide a good prediction of the car's location. This happens faster when there have been changes to the input provided by the user.

Quote from nexttime :

Shouldn't this be the other way round? At lower speeds people use quicker/wackier steering inputs & higher angles. And at higher speeds we all keep it smooth. (If by higher speeds you meant the vehicle speed and not steering wheel rotation)

When you are at higher speeds, you move the steering much smaller amounts. Before today's version, that would be interpreted as very little change to the input. But actually at high speeds your car moves across the road much more for a smaller steering input, that is why the steering-related packet frequency is now increased with speed.


EDIT: I don't claim this is the end of the job. I had some changes today that made sense and are moderate but noticeable enough, in my opinion, to be put out there for testing. It's safe and I want to play safe for now. This is a minor update for the existing public version and I need to be on this for as little time as possible.

Last edited by Scawen, Mon 11 Jan 2021, 20:32.

Thanks for the testing.

To my mind it is still possible that the bad collisions were related to lag and prediction causing excessive intersections rather than being related to VOB at all. As we know bad collisions can happen at any time between unmodified cars. It's true I could do a better job with that.

I understand you asked some people when you saw the collisions and often found out they were using VOB mods. But maybe these mods are just commonly used by people who go to cruise servers?

Quote from Vulgar :

It is obvious that the the current dev team has no desire to either do what others are doing, and or have to deal with the headache of the typical corporate bs.
...

Hi Vulgar, thank you for your long and well written post which I enjoyed reading.

I was happy to see your support for our work and was interested in the other things you said.

I read it when you first wrote it and came back for another read today.

Quote from Vulgar :

Clearly the devs do not need income. A great position to be in.

I agree with most things you said but would like to correct this point.

In fact we do need income but less than a lot of people do. As we want to eat good quality food, keep the kids in clothes as they grow and keep our houses running and it's almost 'necessary' to keep a car on the road (though less so these days, with food delivery services). In recent years LFS income has indeed been a bit too low but the great thing is that people do keep discovering it, so there is always income. It would eventually reduce too much but I'm sure the new update will get it up a bit for a few more years.

Still, without debts to service and if you don't need to go on expensive holidays or keep buying the latest telephone then it's possible to have a very good life even while earning less than most people would expect. Though I am fully aware that my family and I are very lucky, living in a rural part of England, we can go on walks and bike rides on wooded trails and field edges so we don't need to spend a lot of money for entertainment. Though that's not really pure luck - we chose to move away from London 12 years ago because this job allowed it and we knew we would have more space, less pollution and so on.

Through my life I've never cared about wearing clothes with a fashionable name or having a big watch or owning the latest gadgets in order to impress other people. Actually I would find that kind of thing embarrassing. I've always wanted to pay off any debts as soon as possible and only buy what I can afford. So I've not ended up enslaved by the system, having to earn loads of money to be sucked out of my bank account all the time. When I worked as a motorbike courier in London, I was happy any time to work less and earn less. I've always thought that time and peace are more important than money.

I hope that might be interesting, I suppose our way of running our lives is also related to how we have kept LFS going even if it is a slow burn.

Off topic but seemingly somehow related: I hope that when world economies get going again after the social distancing, we may rebuild and run our countries in a slower and less polluting way. What is really the point of traffic jams, crowded trains and long journeys to work in polluted cities?